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METHODS AND SYSTEMS FOR MAKING SECURE ELECTRONIC 

PAYMENTS 

RELATED APPLICATION DATA 

The present application is related to and claims the benefit of U.S. 
5 Provisional Application No. 60/181.224. filed on February 9. 2000, entitled 
"System for Secure and Efficient Internet-based Payments Linked to Checking 
Account." and U.S. Provisional Application No. 60/181.225. filed on February 
9. 2000. entitled "Method and System for Making Anonymous Bectronic 
Payments on the World Wide Web," both of which are expressly incorporated 
10 in their entirety herein by reference. 

BACKGROUND OF THE INVENTION 

Field of the Invention 

The present invention is generally related to electronic commerce and. 
more particularly, to methods and systems for making secure electronic 
15 payments on insecure networks, such as. for example, the Intemet 

Background 

The World Wide Web ("Web") has evolved Into a new commercial 
environment with enormous potential. Fueled by its universal appeal, Instant 
and worldwide access, ease of use and low cost of operation, the Web has 

20 been the location of choice for a surprising number of merchants, vendors and 
service providers alike. 

To realize the full commercial power of the Web, however, It Is 
important to provide efficient payment mechanisms. With a payment- 
processing infrastructure in place, customer transactions can be completely 

25 performed online without requiring In-person or vocal communication. So- 
called "cllck-and-pa/' methods translate to more efficient payment processing 
and reduced operational costs for merchants. 

In conventional payment transactions, customers wishing to purchase 
goods or services are at some point required to give confidential payment 

30 Information to the merchant offering the goods or services. Customers, for 
example, are required to provide a name, address, and confidential payment 
Infomnatlon specific to the customer, such as a debit card number, credit card 
number, or bank account number and routing information. Many people 
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understandably feel uncomfortable using credit cards on-line, and are 
extremely cautious when giving account information over the Internet, This 
caution Is justifiable because, with this information, an interloper has all the 
information necessary to mal<e unauthorized transactions. 

5 Merchants doing business over insecure networl<s attempt to secure 

customer confidential payment information by securing the line of 
transmission using a secure transmission protocol, such as Secure Socl<ets 
Layer ("SSL"), SSL is a transport level technology for authentication and data 
encryption between a Web server and a Web browser. SSL, and other 

10 secure transmission protocols, however, secure the Information only during 
transmission and not at a merchant's site. The customer's confidential 
payment information remains vulnerable to break-in attacks on computer 
equipment and databases at the merchant's end. Furthermore, under 
conventional methods, customers are not protected from impersonation 

15 attacks, also called "man-in-the-middle" attacks, where an Identity thief 
impersonates a vendor and the customer, believing he is dealing with a 
reliable merchant, transmits confidential payment information to the 
impersonator, who then uses the confidential payment information to make 
unauthorized transactions. The lack of methods for combating these types of 

20 security attacks has contributed to an increased credit card theft over the 
Internet and increased transaction costs of legitimate merchants. 

There have been some efforts to improve the security of payment 
transactions over an insecure network. The SET Secure Electironics 
Transaction™ specification, for example, is an open technical standard 

25 developed by Visa and MasterCard, to facilitate secure payment card 

transactions over the Internet. The SET specification uses digital certificates 
to verify the identities of both a merchant and a cardholder. The SET 
specification, however, has proven difficult and costly to implement since it 
requires the installation of specialized software by all parties involved - card- 

30 Issuing banks, credit card processors, participating merchants, and 

customers. Furthermore, deploying SET requires a large investment of time 
and money to distribute, manage, verify and educate participants on the 
proper use of the digital certificates. 
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Thus, it is preferable to design a system which can be used by any 
client machine, be installed at any merchant, and be run from any bank, 
without special hardware or software requirements. 

In summary, the e-commerce community still lacks a simple and easy- 

5 to-use "cllck-and-pay" method and system of making electronic payments 
which promotes a spur-of-the-moment paying habit and which affords 
anonymity, security and accountability. Furthermore, any conventional 
solutions require that ail parties to a transaction undergo changes to hardware 
or Install specialized software and do not often work across all computer 

10 platforms. 

SUMMARY OF THE INVENTION 

The present invention provides methods and systems for securing 
payment over a network from a customer to a merchant A trusted party 
component receives an instruction from the customer to pay the merchant, the 

15 instruction including confidential payment information of the customer. The 
taisted party component creates payment authentication information based on 
the confidential payment information. Based on the payment authentication 
information, the trusted party component pays the merchant on behalf of the 
customer with the confidential payment information of the customer being 

20 disclosed to the merchant. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings provide a further understanding of the 
invention and are incorporated In and constitute a part of this specification. 
The drawings illustrate various embodiments of the invention, and. together 
25 with the description, serve to explain the principles of the Invention. 

Fig. 1 illustrates one embodiment of a method for making electronic 
payments consistent with the present invention; 

Fig. 2 shows an exemplary procedure performed by the PAN 
calculator. 

30 Fig. 3 illustrates another embodiment of a method for making electronic 

payments over an Insecure network consistent with the present invention; 
Fig. 4 Illustrates the functions perfontted by PT Server 140; 
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Fig. 5 Illustrates yet another embodiment of a method for making 
electronic payments consistent with the present invention; 

Fig. 6 illustrates yet another embodiment of a method for making 
electronic payments consistent with the present invention; 
5 Fig. 7 illustrates a system consistent with the present invention; 

Fig. 8 depicts a more detailed diagram of the customer computer 
depicted in Fig, 7; and 

Fig. 9 depicts a more detailed diagram of the PAN server depicted in 

Fig. 7. 

10 DETAILED DESCRIPTION 

The following detailed description of the invention refers to the 
accompanying drawings. Although the description Includes exemplary 
implementations, other Implementations are possible and changes may be 
made to the implementations described without departing from the spirit and 
1 5 scope of the Invention. The following detailed description does not limit the 
invention. Instead, the scope of the invention is defined by the appended 
claims. Wherever possible, the same reference numbers will be used 
throughout the drawings and the following description to refer to the same or 
like parts. 

20 The present invention provides methods and systems for making 

secure electronic payments over the Internet. In accordance with the 
principles of the present invention, when a user instmcts payment to a 
merchant, a user's confidential payment information, is not available to the 
merchant. Confidential payment information includes all information unique to 

25 the customer that is necessary for completing an electronic payment 

transaction. Confidential payment information may include, but is not limited 
to. such Information as, prepaid debit card number, bank debit card number, 
credit card number, expiration date and/or personal identification number 
("PIN'), bank account number and routing information, check number, Beenz 

30 number used for Beenz Internet payments. Rooz number used for Flooz 
Internet payments and digital signature. In methods and systems consistent 
with the present invention, confidential payment information is provided to a 
trusted third party and the trusted third party facilitates the merchant receiving 
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the payment without the merchant having acx^ess to the user's confidential 
account information. 

The Web is the universe of information available to users over the 
world-wide network called the Internet. The Web Is accessed through a body 
5 of software, a set of protocols, and a set of defined conventions for getting at 
the infomnation on the Web. Web browsers, such as MOSAIC®, NETSCAPE® 
or INTERNET EXPLORER®, are software operating on a user's computer, 
referred to as a "client," that allows users to move easily from one Web site to 
another. To "surF* the Web, a user makes an Internet connection and 

10 launches a Web browser. The Web browser contacts a Web site on a server 
over the Internet and requests infomnation or resources. The server locates 
the information and then sends the infomnation to the Web browser, which 
displays the results on the client computer. Web browsers use the HyperText 
Transfer Protocol f HTTP") to communicate between a client computer and a 

1 5 server over the Internet. 

When users surf the Web, they view multimedia web pages composed 
of text, graphics and multimedia content, such as sound and video, in a 
browser. The user may enter a Universal Resource Locator ("URL") In the 
browser specifying a location (server) to visit. The user may also "click" on a 

20 link to forward the user to a new location. When a server finds the requested 
web page, document, or object, the server sends the information back to the 
Web browser. 

A Web browser displays information by interpreting the Hypertext 
Markup Language ("HTML") used to build web pages. The coding in an 

25 HTML files tells the browser how to display the text, graphics, links and 

multimedia files on a web page. The HTML file that the browser receives from 
the server does not have graphics, sound, multimedia files and other 
resources on it. Instead, tiie HTML file contains HTML references to those 
graphics and files. The browser may use tiie references in the HTML file to 

30 find the files on servers, and display as a home page In the browser 

Web browsers typically runs application programs that are written In 
JAVA®, a computer language devetoped by SUN MICROSYSTEMS®, JAVA® 
is an object-oriented programming language that allows programmers to 
create Interactive programs and add multimedia features to home pages. 
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NETSCAPE is an example of a Web browser capable of running JAVA® 
programs. JAVA® programs that run at the client inside a browser are called 
"applets. 

When a user visits a Web site or server that contains JAVA® applets, 
5 the applets maybe downloaded to the user's computer from the server. Once 
an applet is downloaded. It runs automatically. 

The nature of the Internet is that it is an insecure network. As packets 
travel across the Internet, any user could conceivably examine the packets. 
Because of the Internet's insecure nature, there are potential dangers to doing 

10 business online, if a user provides confidential account information on the 
Internet, a third party could steal the account information and other identifying 
information. Software engineers have developed schemes to transmit 
confidential information securely to combat this problem. This is known as 
encryption and decryption. 

15 Inforniation to be sent needs to be encrypted, that is, altered so that to 

third parties the information will look like meaningless garble. The information 
also needs to be decrypted, that is, turned back into the original message by 
the recipient, and only by the recipient. Many complex systems known as 
"cryptosystems," have been created to allow for this kind of encryption and 

20 decryption. 

The heart of understanding how cryptosystems work is to understand 
the concept of "keys." Keys are secret values used by computers in concert 
with complex mathematical formulas to encrypt and decrypt messages. For 
example, if a user encrypts a message with a key, only a user with a matching 

25 key could decrypt the message. There are two kinds of common encryption 
systems; secret-key cryptography, also called symmetric cryptography, and 
public-key cryptography, also called asymmetric cryptography. 

in secret-key cryptography, only one key is used to encrypt and decrypt 
messages. Both the sender and receiver need copies of the same secret key. 

30 In contrast, public-key cryptography uses two keys (a public key and a private 
key). Each user (sender and recipient) has both a public key and a private 
key. The public key is made freely available, while the private key is kept 
secret on the user's computer. The public key can encrypt messages but only 
the private key can decrypt messages that the public key has encrypted. If a 
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sender wants to send a message to a recipient, for example, the sender may 
encrypt the message with the recipient's public key. But only the recipient, 
with the private key, could decrypt and read the message. The public key 
could not decrypt the message. An example of public/private-key 
5 cryptography is the well-known Pretty Good Privacy ("PGR") encryption 
system. 

In methods and systems consistent with the present invention, a 
Trusted Third Party f TTP") guarantees the security of payment transactions 
without requiring many of the involved parties, such as the banking 

10 institutions, transaction processors, and the customers, to make even 
minimal, if any, changes to their cun^ent modes of operation. 

Methods and systems consistent with the present invention are 
depicted In FIG. 1. In one embodiment of the present invention, as shown In 
Fig. 1 . a payment transaction is conducted between a customer at customer 

15 computer 100. a merchant via merchant server 110. and a trusted third party 
fTPP") 120. In general, TPP 120 acts as a transaction processor for 
payments over the Intemet. TPP 120 may be a single entity or, as shown in 
Fig. 3, a collection of entities. 

In Fig. 1, a customer is operating a web broyvser on customer computer 

20 100. The browser uses HTML information transmitted by merchant server 
1 10 to display the merchant's web pages on customer computer 1 00, A 
customer viewing a merchant's web site that wishes to purchase an 
advertised good or service (referred to hereinafter as "item") indicates a 
selected Item and indicates that the customer wishes to pay for the item using 

25 a trusted third party. The customer may indicate desire to pay using a trusted 
third party by, for example, clicking on an icon or other section of the 
displayed web page carrying identification of the trusted third party. The web 
browser on customer computer 100 interprets the customer's Indication and 
transmits the selections to merchant server 1 10 as order information (step 

30 10). Merchant server 110 receives the ordetr information and transmits back 
■ to customer 100 transaction information, such as a payment price, currency 
code, merchant identification number ^merchant ID"), transaction 
identification number ("transaction ID"), transaction date and time, and 
description of goods sold. Merchant and transaction ID •'numbers" may also 
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include letters and symbols. In some embodiments consistent with the 
present invention, merchant server 110 digitally signs the merchant ID and/or 
the transaction ID so that either the customer or TTP 120 can authenticate the 
identify of the merchant 
5 Merchant server 1 1 0 triggers the presentation of a payment window to 

the customer (step 1 1). A payment window is a web page with designated 
fields for entering Information for completing the transaction. In methods and 
systems consistent with the present invention, the payment window may be 
presented to the customer in one or more of the following ways: 

10 Option 1. When paymentis requested, merchant server 110 may invoke a 
TTP-slgned object, such as a Java applet, ActiveX component, or other 
similar object, which is downloaded to and executed by the customer 
computer 100. To invoke the object or applet, merchant server 110 may 
download or otherwise transmit the object or applet to customer computer 1 00 

1 5 and the object or applet runs locally on customer computer 1 00. The object or 
applet is signed by TTP 120. which means that the customer can verify that 
the code can be tmsted to execute on her/his computer. In this case, all 
calculations are performed on customer computer 100 and the object or 
applet functions on behalf of the customer. The applet is signed by the TTP 

20 so that it can be tiirsted to execute without the customer risking her/his 
machine's Integrity. 

Option 2. When payment is requested, merchant server 120 may be 
prompted to look for a TTP-signed browser plug-in or other piece of software 
resident on customer computer 100 and invoke it. The browser plug-in or 

25 other software presents the payment to the customer. The browser plug-in or 
client software may have been installed, for example, at the time the customer 
applied for or activated a new account witii TTP 120, or at any time during 
communication with TTP 120. In this case, the browser plug-in or other 
software runs locally on customer computer 100 and perfonns all calculations 

30 on customer computer 100. 

Option 3. When payment Is requested, the customer's web browser is 
-redirected- to a web page on TTP 120. The customer may be redirected by. 
for example, prompting tiie customer's web browser to locate the URL of a 
payment window running on TTP 120. The customer's web browser locates 
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the URL and connects to TTP 120 using any commonly available means for 
establishing a secure connection, such as SSL. TTP 120 sends HTML 
instructions for displaying the payment window to the customer over the 
secure connection and any data entered into the payment window is 
5 transmitted to TTP 120 over the secure connection. Using Option 3, it is 
possible to have the user's interface look the same without any special 
software running on the customer's computer. All special software for 
implementing the present invention would be hosted on TTP 120 and TTP 
120 could easily change the software code or make upgrades. Furthermore, 
1 0 redirection Is possible on a variety of different platforms - effectively every 
browser that supports the SSL protocol. 

Option 4. Alternatively, when payment is requested, merchant server 1 10 
redirects the customer's web browser to a web page on TTP 120. The 
customer's web browser locates the URL and connects to TTP 120 using any 

1 5 commonly available means for establishing a secure connection, such as 
SSL. TTP 120 downloads a Java applet or browser plug-In or other software 
to customer computer 110 and Invokes by it The software is running on 
customer computer 110 and transmits all entered data to TTP 120. 

Once the customer Is presented with a payment window using one of 

20 the options described above, the customer enters into the payment window 
one or more payment tender types (such as, for example. ATM. prepaid card, 
debit card, credit card, and non-trad Itlonal payment tenders such as frequent 
flyer numbers (to use airline miles), Beenz. FIooz, Reward Points (to use 
membership reward points), tokens, gift certificates, etc.) and confidential 

25 payment information. Alternatively, the payment window may retrieve the 
customer's confidential payment information from a storage location on 
customer computer 100 or TTP 120, decrypt the information if it is stored in an 
encrypted format, and display the confidential payment information in the 
appropriate field or fields so that the customer does not have to enter the 

30 information manually. * 

In embodiments using options 1 or 2, the one or more payment tender 
types, confidential payment Information, and transaction information are 
available to software operating on customer computer 110. In embodiments 
using options 3 or 4, the one or more payment tender types, confidential 
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payment information, and transaction information are made available by TTP 
120 (step 12). 

In methods and systems consistent with the present invention, the 
customer's confidentiai payment infomiation and transaction information is 
5 used to generate a Payment Authorization Number (or TAN"). As described 
herein, the PAN may be generated by a TTP-signed applet, object, or browser 
plug-in operating on customer computer 110, or software operating on TTP 
120. The software that generates the PAN (whether resident on customer 
computer 110 or TTP 120) will be referred to as the "PAN calculator." 

■'O Fig- 2 shows an exemplary procedure performed by the PAN 

calculator. When the customer selects goods to buy and indicates payment 
by trusted third party, the PAN calculator checl<s to see If the customer's 
confidential payment infonnation is already stored (step 205). If it is stored, 
the PAN calculator extracts the customer's stored confidential payment 

1 5 information (step 2 1 0). If the confidential payment infonnation is encrypted, 
the confidential payment information may be decrypted using the PAN 
server's key and the customer's PIN (step 210). In this case, the customer 
inputs his or her PIN but does not need to enter other confidential payment 
infonnation. The PAN calculator verifies that the PIN Input by the customer 

20 results in a con-ect decryption of the card number or other payment 
authentication information (step 220). 

If the customer is mal<ing the payment using a new payment tender 
type or new confidential payment infonnation that TTP 120 has not seen 
before (step 205), the PAN calculator aslts the customer if s/he wants to store 

25 the confidential payment Information (step 225). if yes, the PAN calculator 
encrypts the confidential payment information using the PAN server's key and 
the user's PIN, and saves it either at the customer's computer or in the PAN 
server (step 230). 

If the financial institution issuing the payment tender chosen by the 
30 customer requires use of a PIN, the PAN calculator encrypts the PIN using 
algorithms and keys specific to the issuing financial institution (steps 240). 
The PAN calculator performs encryption of the user-sensitive card/check 
number and other data as well as super-encryption of the encrypted PIN using 
a symmetric or asymmetric algorithm, e.g.. Simple Symmetric Encryption 
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Algorithm based on SHA-I (SSEA-SHA1) (step 245), The PAN calculator 
saves the encrypted data and transaction information in the PAN server 
database (step 250) so as to keep record of the customer's confidential 
payment Information. 
5 = The PAN calculator generates a PAN (step 260). In one embodiment 

of the present invention, the PAN is a digital signature of the customer's 
confidential payment Infomnatlon. The PAN may be generated, for example, 
using any known means for generating a digital signature. In one 
embodiment of the present invention, the PAN is generated by computing a 

1 0 Hash-based Message Authentication Code (such as 

"HMAC-SHA-r) of the confidential payment information. Methods for 
generating HMACs are well known by those skilled in the art and are 
described in further detail, for example, In "Keying Hash Functions for 
Message Authentication," Advances in Cryptology, Crypto 96 Proceedings. 

15 Lecture Notes in Computer Science, Vol., 1 109 (Springer-Veriag. N. Koblltz. 
ed.), 1996. by Mihlr Bellare et al. 

In one exemplary method, the PAN may described as: 

PAN = HMACKey (Customer confidential payment Infonnation), 
where HMAC Is a Hash-based message authentication code, and the "key" is 

20 the customer's secret key. In general, the customer's "secret key" may be 
either a secret key shared between TPP 120 and the customer (as In a 
symmetric key cryptosystem) or the private key of a public-private key pair 
assigned to the customer (as in a asymmetric key cryptosystem). Since 
HMAC is a symmetric-key operation, the secret key In this case is sharad 

25 between TTP 120 and the customer. In an alternative embodlrhent. the PAN 
may be a digital signature of the customer's confidential payment information 
and the transaction infomiation. If the PAN Is a digital signature of the 
customer's confidential payment infonnation and the transaction infomiation, 
the PAN is transaction-specific, that is, each transaction will have a unique 

30 PAN. When HMAC Is used, this PAN may be described as: 

PAN = HMACKey (Customer confidential payment Infomiatlon/transaction 
infonnation), 

where HMAC is a Hash-based message authentication code, and the "key" is 
the customer's secret key. 
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Referring again to Fig. 1. customer computer 100 forwards the PAN to 
merchant server 1 1 0 (step 1 4). Merchant server 1 1 0 verifies that the 
transaction information has not been altered by, for example, retrieving the 
transaction Information from Its own database based on the specific 
5 transaction i D retumed from the customer computer 1 1 0. and confirming that 
the amount, the cun-ency code and (if present) the date/time and description 
of the transaction are the same as those retumed from the customer 
computer 110. If the transaction information has not been altered, merchant 
server 1 10 signs the PAN and submits the PAN to TTP 120 (step 15). TTP 

10 120 authenticates the PAN by recalculating it and comparing it with the 
submitted PAN. TTP 120 verifies the customer's confidential payment 
Infonnatlon by checl<ing, for example, whether the cards used by the 
customer to create the signature were valid and had not expired, there are 
sufficient funds in the account, and the merchant accepts this method of 

1 5 payment. If the transacUon information passes the proper validations, TTP 
120 authorizes payment and executes payment to the merchant. TTP 1 20 
notifies merchant server 1 10 that payment has been executed (step 16). The 
notification may include a digital signature of TTP 120 which can be verified 
by merchant server 1 10. When payment is received, merchant server 110 

20 notifies the customer via customer computer 1 1 0 that payment has been 

received (step 17). If the transaction does not pass validation. TTP 120 sends 
an error message to merchant server 110, which notifies customer computer 
1 10 that the payment was not successful. 

In some embodiments of the present invention, TTP 120 is a collection 

25 of entities. As sho\m in Fig. 3, TPP 1 20 may comprise PAN server 130, 

Payment Transaction Server ("PT Server") 1 40, Transaction Processor 1 60, 
and one or more databases, such as Database 160. PAN server 130 and PT 
Server 140 may be implemented on tiie same computer or separate 
computers. 

30 Fig. 3 Illustrates ttie steps of an embodiment where the PAN calculator 

is software running on customer computer 100, that Is, eltiier a TTP-sIgned 
object or applet invoked by merchant server 1 10 or a TTP-signed browser 
plug-in or other software. In Fig. 3. tiie customer indicates a selected Item 
and indicates a desire to pay for the item using a trusted third party. The 
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customer may indicate desire to pay, for example, by clicking on an icon or 
other section of tlie displayed web page carrying identification of the trusted 
third party. The web browser on customer computer 100 interprets the 
customer's Indication and transmits the selections to merchant server 1 10 as 
5 order Information (step 30). Merchant server 1 1 0 receives the order 

information and transmits back to customer 100 transaction Infomiation. In 
some embodiments of the present invention, merchant server 110 digitally 
signs the merchant ID and/or the transaction ID so that either the customer or 
TTP 120 can authenticate the Identity of the merchant. 

10 Merchant server 110 triggers the presentation of a payment window to 

the customer using option 1 or 2 described above with respect to Fig. 1 (step 
31). Once the customer is presented with a payment window, the customer 
enters Into the payment window one or more payment tender types and 
confidential payment types. Alternatively, the payment window may retrieve 

15 the customer's confidential payment information from a storage location on 
the customer computer 100 or TTP 120 and display the confidential payment 
information in the appropriate field or fields so that the customer does not 
have to enter the information manually. The one or more payment tender 
types, confidential payment information, and transaction Information may 

20 optionally be transmitted to PAN Server 1 30 of TTP 1 20. 

A PAN Calculator operating on customer computer 100 generates a 
PAN according to the steps of the method illustrated by Fig. 2. The PAN is a 
digital signature of the transaction and may be directly or indirectiy related to 
the type of payment chosen. For example, if a customer elects to pay with a 

25 prepaid card, the digital signature sent to the merchant may be computed 

from tiie card number and PIN either specific to the card or the user. When a 
credit card is used, the signature may be created by PAN server 1 30 and may 
be bound to the credit card number in database 160, The PAN may be 
generated, for example, using any known means for generating a digital 

30 signature. In one embodiment of the present invention. \he PAN is generated 
by computing a Hash-based Message Authentication Code ("HMAC") of One 
customer's confidential payment information. In this case, the PAN may be 
described as: 

PAN = HMACKey (Customer confidential payment Information), 
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where HMAC is a Hash-based message authentication code, and the "loy" Is 
the customer's secret key. In general, the customer's "secret key" may be 
either a secret key shared between TTP 120 and the customer (as in a 
symmetric key cryptosystem) or the private key of a public-private key pair 
5 assigned to the customer (as in a asymmetric key cryptosystem). Since 
HMAC Is a symmetric-key operation, the secret key in this case is shared 
between TTP 120 and the customer. In an alternative embodiment, the PAN 
may be a digital signature of the customer's confidential payment information 
and the transaction information. If the PAN is a digital signature of the 
1 0 customer's confidential payment infomriation and the transaction information, 
the PAN is transaction-specific, that is, each transaction will have a unique 
PAN. When HI\/IAC is used, this PAN may be described as: 
PAN = HMACKey (Customer confidential payment Infonnation/transaction 
information). 

1 5 where HMAC is a Hash-based message authentication code, and the "key" is 
the customer's secret key. Alternatively, the PAN may also comprise an 
encryption of the customer's confidential payment infomiation as follows: 

PAN = {ENCKeyi (Customer's confidential payment Infomriation), 
HMACKey2 (Customer's confidential payment infomriation )}, where 

20 ENC Is an encryption function (symmetric or asymmetric), and "keyl ' is a 
public key of PT Server 140 and ''key2" is the customer's secret key. 

Customer computer 100 fonwards the PAN to merchant server 110 
(step 32). Merchant server 1 10 verifies that the payment order information 
has not been altered. Merchant server 110 signs the PAN and submits a 

25 payment request and the signed PAN to PT Server 140 (step 33). 

Fig. 4 illustrates the functions perfomied by PT Server 140. PT Server 
1 40 receives the payment request with the accompanying PAN signed by 
merchant server 110 (step 405). PT Server 140 verifies the signature of the 
merchant (step 41 0). If the signature does not verify, the transaction is 

30 rejected (step 465). PT Server 140 obtains the PAN from the payment 

request and verifies it using the customer's secret key (shared with TTP 120) 
or the customer's public key (step 41 5). If the PAN cannot be verified, the 
transaction is rejected (step 465). 
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PT Server 140 may allow "split-tender^ payments. A "split-tender 
payment" is one where a part of the purchase amount is charged to the one 
payment tender, such as the customer's credit card, and another part is 
charged to another tender, such as the customer's prepaid card, therefore 
5 multiple tender types can be used per transaction. In step 420, PT Server 
140 determines the payment tender types specified by the customer. For 
each payment tender type specified, PT Server 140 checks whether payment 
with the payment tender type has been preauthorized (step 425). If payment 
with the payment tender type has been preauthorized, PT Server 140 gets the 
10 customer's confidential payment information and the transaction information 
(step 430) and releases the funds by sending instructions to Transaction 
Processor 150 to execute the payment transaction (step 435) (also Fig, 3. 
step 34). 

If payment with a payment tender type was not preauthorized, PT 

15 Server 140 gets the customer's confidential payment information and the 

transaction information (step 440) and verifies the information (step 445). 1^ 
Server 140 transmits the customer's confidential payment information to 
Transaction Processor 150 (Fig. 3, step 34). Transaction Processor 15 
receives payment requests from PT Server 140 (and in some cases, from 

20 PAN Server 1 20), and redirects them to the financial Institution that issued the 
chosen payment tender. The financial institution verifies the transaction In 
real time and sends the request back to Transaction Processor 150. If the 
funds are available to clear the transaction, Transaction Processor 150 
authorizes payment and Infonns PT Server 140 (Fig. 3, step 35). 

25 Returning now to Fig. 4, if Transaction Processor 150 notifies PT 

Server 140 that sufficient funds are available to dear the transaction (step 
460), the funds are released (step 435). If sufficient funds are not available to 
clear the transaction, an error message is returned to PT Server 140. PT 
Server 140 updates the transaction history Infonmation saved in a transaction 

30 history database. Steps 425 through 470 are repeated for each payment 

tender type (step 480). PT Server 140 computes a signature of the particular 
transaction and transmits the signed transaction to merchant server 110 
notifying the merchant that funds have been released or that payment was 
unsuccessful (step 435) (also Fig. 3. step 36). 
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Merchant server 110 notifies the customer via customer computer 100 
that payment was successful or unsuccessful (step 37). 

Fig. 6 illustrates an embodiment where the PAN calculator is resident 
on TIP 120. As in the embodiments above, the customer indicates a 
5 selected item and indicates a desire to pay for the item using a trusted third, 
party. The customer may indicate desire to pay, for example, by clicking on 
an Icon or other section of the displayed web page carrying Identification of 
the trusted third party. The web browser on customer computer 100 interprets 
the customer's indication and transmits the selections to merchant server 110 

10 as order Information (step 60). Merchant server 110 receives the order 

information and transmits back to customer 100 transaction infonnation. In 
some embodiments of the present invention, merchant server 110 digitally 
signs the merchant ID and/or the transaction ID so that either the customer or 
TTP 120 can authenticate the kJentity of the merchant. 

1 5 Merchant server 1 1 0 triggers the presentation of a payment window to 

the customer using option 3 or 4 described above with respect to Fig. 1 (step 
61), Once the customer is presented with a payment window, the customer 
enters into the payment window one or more payment tender types and 
confidential payment types. Alternatively, the payment window may retrieve 

20 the customer's confidential payment information from a storage location on 
the customer computer 100 or TTP 120 and display the confidential payment 
infomiation in the appropriate field or fields so that the customer does not 
have to enter the information manually. The one or more payment tender 
types, confidential payment information, and transaction information are to 

25 PAN Server 1 30 of TTP 1 20 (step 62). 

Optionally. PAN Server 130 may request preauthorization of the 
payment amount from Transaction Processor 150 (step 63). Transaction 
Processor 150 may query the account Issuing financial institution to confinn 
that sufficient funds will be available (in the case of a debit account) or 

30 whether a charge limit is exceed (in the case of a credit account). Transaction 
Processor 160 notifies PAN Server 130 whether the payment is preauthorized 
or rejected and may also provide other infonnation, such as balance 
information (step 64). 
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A PAN Calculator operating on PAN Server 130 generates a PAN 
according to the steps of the method illustrated by Fig. 2 The PAN may be 
generated, for example, using any known means for generating a digital 
signature. In one embodiment of the present Invention, the PAN is generated 
5 by computing a Hash-based Message Authentication Code ("HMAC") of the 
customer's confidential payment Information. In this case, the PAN may be 
described as: 

PAN = HMACKey (Customer confidential payment Information), 
where HMAC is a Hash-based message authentication code, and the "key" is 

1 0 the TTP's secret key. In general, the customer's "secret key" may be either a 
secret key shared between TTP 120 and the customer (as in a symmetric key 
cryptosystem) or the private key of a public-private key pair associated with 
the customer (as in an asymmetric key system). Since HI\/IAC is a symmetric- 
key operation, the secret key in this case is shared between TTP 120 and the 

15 customer. In an altemative embodiment, the PAN may be a digital signature 
of the customer's confidential payment information and the transaction 
infonnatlon. If the PAN is a digital signature of the customer's confidential 
payment infomnation and the transaction Information, the PAN Is transaction- 
specific, that Is, each transaction will have a unique PAN. When HMAC is 

20 used, this PAN may be described as: 

PAN = HMACKey (Customer confidential payment Information/transaction 
Information), 

where HMAC is a Hash-based message authentication code, and the "key" is 
the customer's secret key. Alternatively, the PAN may also comprise an 

25 encryption of the customer's confidential payment information as follows: 
PAN = {ENCKeyi (Customer's confidential payment information), 
HMACKey2 (Customer's confidential payment information)}, where 
ENC is an encryption function (symmetric or asymmetric), and "keyi" Is a 
public key of PT Server 140 and "key2*' is the customer's secret key. 

30 PAN Server 130 transmits the PAN to Customer computer 100 (step 

65), which forwards the PAN to merchant server 110 (step 66). Merchant 
sen/er 110 verifies that the payment order information has not been altered. 
Merchant server 110 signs the PAN and submits a payment request and the 
signed PAN to PT Server 140 (step 67). 



SUBSTITUTE SHEET (RULE 26) 



wo 01/59731 



PCT/USOl/04251 



Fig. 4 Illustrates the functions performed by PT Server 140. PT Server 
140 receives the payment request with the accompanying PAN signed by 
merchant server 110 (step 405), PT Server 140 verifies the signature of the 
merchant (step 410), If the signature does not verify, the transaction is 
5 rejected (step 465). PT Server 140 obtains the PAN from the payment 

request and verifies it using the customer's secret key (shared with TTP 120) 
or the customer's public key (step 415). If the PAN cannot be verified, the 
transaction is rejected (step 465). 

PT Server 140 may allow "split-tender" payments. A "split-tender 

10 payment" is one where a part of the purchase amount is charged to the one 
payment tender, such as the customer's credit card, and another part is 
charged to another tender, such as the customer's prepaid card, therefore 
multiple tender types can be used per transaction. In step 420, PT Server 
140 determines the payment tender types specified by the customer. For 

1 5 each payment tender type specified, PT Server 1 40 checks whether payment 
with the payment tender type has been preauthorized (step 425). If payment 
with the payment tender type has been preauthorized, PT Server 140 gets the 
customer's confidential payment information and the transaction information 
(step 430) and releases the funds by sending instructions to Transaction 

20 Processor 1 50 to execute the payment transaction (step 435) (also Fig. 3. 
step 68). 

If payment with a payment tender type was not preauthorized, PT 
Server 140 gets the customer's confidential payment infomiation and the 
transaction information (step 440) and verifies the information (step 445). PT 

25 Server 1 40 transmits the customer's confidential payment infomnation to 
Transaction Processor 150 (Fig. 3, step 68). Transaction Processor 15 
receives payment requests from PT Server 140 (and in some cases, from 
PAN Server 120). and redirects ttiem to the financial institution that issued tiie 
chosen payment tender. The financial institution verifies the transaction in 

30 real time and sends the request back to Transaction Processor 150. If the 
funds are available to clear the transaction. Transaction Processor 160 
autiiorizes payment and Infomis PT Server 140 (Fig. 3, step 69). 

Returning now to Fig. 4. if Transaction Processor 150 notifies PT 
Server 140 that sufficient funds are available to clear the transaction (step 
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450), the funds are released (step 435). If sufllcient funds are not available to 
clear the transaction, an error message Is returned to PT Server 140. PT 
Server 140 updates the transaction history information saved In a transaction 
history database. Steps 425 through 470 are repeated for each payment 
5 tender type (step 480). PT Server 140 computes a signature of the particular 
transaction and transmits the signed transaction to merchant sender 110 
notifying the merchant that funds have been released or that payment was 
unsuccessful (step 435) (also Fig. 3, step 70). Merchant server 110 notifies 
the customer via customer computer 100 that payment was successful or 

10 unsuccessful (step 71). 

If the PAN contains the payment signature but does not contain the 
encryption of the customer's confidential payment information, PT Server 140 
can obtain the customer's confidential payment information through shared 
database 160 to obtain the necessary infomiatlon needed to proceed with the 

15 payment transaction. 

In some embodiments consistent with the present Invention, the 
customer's secret key is provided by PAN server 130 and shared with PT 
server 140 such that PT Server 140 can verify the PAN. Alternatively, the 
customer's secret key is not shared by PT Server 140. but PT Server 140 can 

20 verify the PAN by using the customer's public key. 

FIG. 6 illustrates an embodiment consistent with the present invention 
where the merchant perfomis only one contact with the TTP In a mutually- 
signed communication exchange. Specifically, as shown in FIG. 6. a 
customer indicates a selected item and Indicates a desire to pay for the item 

25 using a trusted third party. The customer's web browser on customer 

computer 100 interprets the customer's indication and transmits the selections 
to merchant server 1 10 as order information (step 80). Merchant server 110 
receives the order information and transmits back to customer computer 100 
the order Information and transaction information (step 81). Merchant server 

30 110 may optionally digitally sign the order information, the transaction 
information, or both. Merchant server 1 10 redirects the customer's web 
browser to Customer Computer 100 and triggers the presentation of a 
payment window to the customer (step 82). 
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In methods and systems consistent with the present invention, the 
payment window may be generated using options 3 and 4 described in more 
detail above. Once the customer Is presented with a payment window, the 
customer enters into the payment window one or more payment tender types 
6 and confidential payment types. Aitematively. the payment window may 
retrieve the customer's confidential payment Information from a storage 
location on the customer computer 100 or TTP 120 and display the 
confidential payment information in the appropriate field or fields so that the 
customer does not have to enter the information manually. The one or more 

1 0 payment tender types, confidential payment information, and transaction 
infonnation are transmitted to PAN Server 130 of TTP 120 (step 82). 

Optionally, PAN Server 130 may request preauthorization of the 
payment amount from Transaction Processor 150 (step 83). Transaction 
Processor 150 may query the account issuing financial institution to confirm 

1 5 that sufficient funds will be available (in the case of a debit account) or 

whether a charge limit is exceed (in the case of a credit account). Transaction 
Processor 150 notifies PAN Server 130 whether the payment Is preauthorized 
or rejected and may also provide other information, such as balance 
information (step 84). 

20 In this embodiment, generating a PAN Is optional. If generated, PAN 

Calculator operating on PAN Server 130 generates a PAN according to the 
steps of the method illustrated by Fig. 2. The PAN may be generated, for 
example, using any l<nown means for generating a digital signature. In one 
embodiment of the present invention, tiie PAN Is generated by computing a 

25 Hash-based Message Authentication Code ("HMAC") of the customer's 

confidential payment information. In this case, the PAN may be described as: 

PAN = HMACKey (Customer confidential payment infonnation), 
where HMAC is a Hash-based message autiientlcation code, and the "ke/' is 
tiie TTP's secret key. In general, the TTP's "secret key" may be either a 

30 secret key shared between TPP 120 and PT Server 140 (as In a symmetric 
key cryptosystem) or tiie private key of a public-private key pair assigned to 
the customer (as in a asymmetric key cryptosystem). Since HMAC is a 
symmetric-key operation, the secret key in tills case is shared between TTP 
120 and PT Server 140. In an alternative embodiment, the PAN may be a 
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digital signature of the customer's confidential payment mfonnatfon and the 
transaction information. If the PAN is a digital signature of the customer's 
confidential payment information and the transaction information, the PAN Is 
transaction-specific, that Is, each transaction will have a unique PAN. When 
5 HMAC is used, this PAN may be described as: 

PAN = HMACKey (Customer confidential payment Infonmation/transaction 
infomnation), 

where HMAC is a Hash-based message authentication code, and the **key" is 
the customer's secret key. Alternatively, the PAN may also comprise an 

10 encryption of the customer's confidential payment information as follows: 
PAN = {ENCKeyi (Customer's confidential payment information), 
HMACKey2 (Customer's confidential payment infonnation)}. where 
ENC is an encryption function (symmetric or asymmetric), and "keyl" is a 
public key of PT Server 140 and "keya" is the customer's secret key. 

15 PAN Server 130 transmits the PAN to PT Server 140 (step 85). PT 

Server 140 receives the payment request with the accompanying PAN from 
PAN Server 1 30. PT Server 140 verifies the PAN using the customer's secret 
key (shared with TTP 120) or the customer's public key. If the PAN cannot be 
verified, the transaction Is rejected. 

20 PAN server 1 30 sends a payment request to PT server 140 (step 86). 

If pre-authorization or account balance information was received In step 84, 
the pre-authorlzation and/or account balance information may be also 
transmitted to PT Server 140 in step 85. If PT server 140 receives a 
p reauthorization in step 85. PT Server 140 sends a request to Transaction 

25 Processor 1 50 to execute the payment transaction (step 86). If pre- 
authorization or account balance infonnation was received in step 84, the pre- 
authorlzation and/or account balance information may be also transmitted to 
Transaction Processor 150. Transaction Processor 150 authorizes payment 
and infonns PT server 140 (step 87). PT server 140 confimis payment to 

30 PAN Server 130 (step 88), PAN S6rver 1 30 returns a PAN to Merchant 
Server 1 10 (step 89). The PAN Is a digital signature of the customer's 
confidential payment information and created by PAN Server 130 using one of 
the meOiods described above. Merchant server 110 receives the PAN and 
verifies PAN Server 130's signature. If payment was successful, merchant 
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server 1 1 0 Informs the customer of successful payment (step 90). If payment 
was unsuccessful, merchant server 110 informs the customer that the 
payment was rejected or any error messages (step 90). 

By redirecting the customer to PAN Server's site. PAN servers are able 
5 to perform computations on behalf of the customer in addition to PAN 
generation such as, for example. 

1 . Other Keyed operations: In addition to the above. PAN Server can use 
other symmetric or asymmetric keys to perform operations on behalf of 
the client. In other words, the PAN Server can act as a trusted third 

10 party for any other computations involving keys for the customer. 

These keys can either be provided by the customer, or stored by the 
PAN Server and indexed by the user's card number(s) or other indexes 
provided by the user. For example, the PAN Server can act as a 
remote pin pad to encrypt a customer's ATM PIN using DES, for 

15 Internet transactions with Debit or ATM cards, A pin pad Is a device 

used by customers to enter PINS. Some pin pads, such as the PINpad 
1000, support Message Authentication Code ("MAC") and use MACs to 
protect debit card transaction during its transfer to a host. 

2. Wallet operations: The PAN Server can also act as a wallet for 
20 customers. For example, customers can store their credit card 

infomiation in the redirected PAN Server window, and the window can 
then fill this Information automatically for the customer for every 
purchase. 

3. Accommodation of a new payment tender: The PAN server can 

25 accommodate, due to Its nature, new payment tenders, combinations 

of more than one payment tenders, and even client-based payment 
solutions. This is because it is built as a web page, and therefore it can 
perfomn all the operations that a merchants site could. Possible 
additions are: detection of client hardware/software and decision as to 

30 whether to use a client-based HSM (such as a smart card) for 

payments; detection of client platform and modification of behavior 
(e.g., for WAP payments); and accommodation of other payment 
signatures and message sets (e.g., for SET support). 
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The PAN server may or may not be connected to the TTP2 payment 
server. The fact that it can be independent allows it to be run from a separate 
server and to be secured in a separate environment- 

In addition to the above, the wallet can also allow customers to view 
5 card balances (and In case of prepaid card, original card face value), view 
card transaction history, change card PIN, and in general perform all the 
operations that could otherwise be performed by visiting PAN Server's or an 
affiliate's web site. In the case of html redirection, this boils down to the front- 
end Interface (html page design) of the wallet, since the customer already is at 
1 0 the PAN Server's or an affiliate's web site. In the case of the plug-in or applet, 
additional functionality is required to allow those pieces to communicate to 
PAN Server's website to obtain or submit the information required for each 
action. 

Methods and systems consistent with the present invention provide 

15 security to financial institutions and merchants by guarding against parallel 
attacks. If, for example, a customer tries to use the full amount of a card on 
two different web sites at the same time (I.e., double-spend) only one 
transaction will succeed, because transactions are cleared In real time 
through a single database. Therefore, If two transactions for the same card 

20 arrive in parallel, they will be sequenced; the first one will succeed while the 
second will fail with an "insufficient funds" message. Furthermore, methods 
and systems consistent with the present invention guard against adversarial 
changes of customer's confidential payment information. An adversary 
cannot alter the payment order Infomnatlon because the merchant will detect 

25 the changes and abort the transaction. Methods and systems consistent with 
the present invention may also provide Immunity against replay attacks. A 
reply attack Is a situation where the merchant sends the same payment 
request more than once. Although the payment request from the merchant to 
PT Server 140 In step 27 of Fig. 2 can be replayed either legitimately (for 

30 example, if the communication failed the firist time) or by an adversary, the 
replay will not result in duplicate charges because no payment action is taken 
if the same PAN has been seen in the past. Because the PAN is unique for 
every transaction. PT server 140 can determine If the PAN Is being used 
again. Methods and systems consistent with the present invention protect a 
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merchant against non-repudiation through the use of digital signatures. An 
existentially unforgeable signature is created at payment time and guarantees 
user security as long as the tender type used cannot be expanded (e.g., the 
adversary cannot guess other parties' credit card numbers and PINs, or 

5 guess/forge checl< numbers). This Is realized by not allowing the merchant to 
change the customer's confidential payment information of the customer. 

Methods and systems consistent with the present invention allow a 
customer to remain anonymous to the merchant, in the course of the 
payment transaction, the merchant only sees the digital signature of the 

10 customer (PAN) and. as long as the merchant receives payment, does not 
need to verify the customer's identity. If the customer desires full anonymity, 
for example, from all parties including the trusted third party, the customer 
may use other payment methods, such as a prepaid card or blind signature- 
based digital signature. 

15 Fig. 7 shows an exemplary system configuration consistent with the 

present invention. Systems consistent with the present invention comprise a 
customer computer 100 and a merchant server 110 connected via an 
insecure network 720 with a PAN server 130 and a payment transaction 
fPT) server 140. PT Server 140 is connected to Transaction Processor 150. 

20 via a secure financial network 730. Financial network 730 may be physically 
secure or secured via the use of commonly recognized protocols for secure 
transmission, such as SSL. Transaction Processor 150 may optionally be 
connected with PAN sen/er 130 via financial network 730. Alternatively or 
additionally, PAN sen/er 130 and PT Server 140 may be connected directly 

25 (that Is, not via network 720 or financial network 730), 

A customer uses customer computer 1 00 to provide various 
information to merchant sen/er 120 and PAN server 130. Customer computer 
100 may be any device comprising the components shown in Fig. 8, including, 
but not limited to, a traditional personal computer, a WAP-enabled cellular 

30 phone. webTV™-type device, hand-held personal digital assistant, such as a 
Palm Pilot™, or other similar device. 

PAN server 130 transmits and receives secure web pages from a 
browser on customer computer 1 00 using HTML or Java. PAN server 1 1 3 
also contains a database that may store information associated with the 

SUBSTITUTE SHEET (RULE 26) 



wo 01/59731 



PCTAJSOl/04251 



25 

wallets. The web pages (front-end) and databases (back-end) are further 
described below. 

Merchant server 110 authorizes transactions using a merchant toolkit 
(not shown). Merchant server 1 1 0 is also capable of transmitting and 
5 receiving secure web pages from a browser on customer computer 100. 
Transaction processor 150 can be a well-known financial entity used to 
process payments (e.g., credit card, debit card, or ATM payment) at a store 
location (point of sale). 

Although only one customer computer 100 is depicted, one skilled in 
10 the art will appreciate that the system may contain many more customer 
computers and additional customer sites. Similarly, plural merchant servers 
110 and sites can be accommodated in the system. 

As shown in FIG. 8, customer computer 110 may contain a memory 
820, a secondary storage device 830, a central processing unit (CPU) 840. an 
15 input device 850, and a video display 860. Memory 820 includes browser 822 
that allows users to interact with various servers by transmitting and receiving 
files. 

As shown in FIG. 9, PAN server 130 may include a memory 910. a 
secondary storage device 920, a CPU 930, an input device 940, an optional 

20 video display 950. and an optional encryption device 960. Memory 910 
includes web software 912 and wallet software 914. Web software 912 
transmits and receives web pages in a secure manner. Although web 
software is described in this particular embodiment of the PAN server, the 
PAN server may interact with customers In other ways such as, voice 

25 prompts, call centers, or kiosks. Wallet software 914 creates wallets for 
various customers. Wallet software 914 contains various keys used to 
authorize and/or encrypt a customer's confidential payment Information (e.g., 
card numbers and PINs). The encrypted key is used to transmit secure 
information to and from customers and merchants. 

3Q Secondary storage device 920 optionally contains a database 922 that 

stores wallet Infonnation. such as card numbers, merchant data (e.g., ID and 
transaction requests), information about various payments, and signatures 
with respect to the wallet. 
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The above-described embodiments acxjording to the present invention 
may be conveniently implemented using conventional general purpose digital 
computers programmed according to the teachings of the present 
specification, as will be apparent to those skilled In the computer art. 
5 Appropriate software coding can readily be prepared by skilled programmers 
based on the teachings of the present disclosure, as will be apparent to those 
skilled In the software art. Such a software package can be a computer 
program product that employs a storage medium including stored computer 
code which is used to program a computer to perfomi the disclosed function 

10 and process of the present invention. Also, what is described above as being 
stored in a memory may be stored on or read from other computer-readable 
media, such as secondary storage devices, like hard disks, floppy disks, and 
CD-ROM; a canrier wave received from a network like the Internet; or other 
forms of ROM or RAM. 

^5 In addition to those already mentioned above, persons of ordinary skill 

will realize that many modifications and variations of the above embodiments 
may be made without departing from the novel and advantageous features of 
the present invention. Accordingly, all such modifications and variations 
are Intended to be included within the scope of the appended claims. The 

20 specification and examples are only exemplary. The following claims define 
the true scope and sprit of the invention. 
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WE CLAIM : 

1 . A method for securing payment over a network from a customer to a 
merchant, perfomned by a trusted party component, the method comprising: 

receiving a request from the customer to pay the merchant, the request 
5 including a transaction Information; 

obtaining confidential payment information of the customer; 
generating payment authentication infomiation based on the 
confidential payment information; and 

facilitating payment to the merchant without disclosing the confidential 
1 0 payment information of the customer to the merchant by transmitting 

• Instoictions to pay the merchant on behalf of the customer and the payment 
authentication information to a payment component. 

2. The method of claim 1 , wherein the payment authentication information 
is generated based on the confidential payment infomiation and the 

15 transaction information. 

3. The method of claim 1 , wherein the payment authentication information 
comprises a digital signature determined based on a secret key of the 
customer. 

4. The method of claim 1 , wherein the trusted party component is a 
20 computer program signed by a trusted third party, spawned by a first 

computer of the merchant, and executed on a second computer of the 
customer, 

5. The method of claim 1 , wherein the trusted party component is a 
computer program signed by a trusted third party, installed in a first computer 

25 of the customer, and invoked by a second computer of the merchant. 

6. The method of claim 1, wherein the trusted party component executes 
on a computer of a trusted third party. 

7. The method of claim 1 , wherein the trusted party component is a 
computer program spawned by or downloaded from a first computer of a 

30 trusted third party and executed on a second computer of the customer. 

8. The method of claim 1 , further comprising: 

verifying, by the payment component, the payment authentication 
information. 

9. The method of claim 8, further comprising: 
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paying the merchant, if the payment authentication Infomiation is 
verified. 

10. The method of claim 9, wherein the transaction Information includes a 
transaction amount and paying comprises instmcting at least one financiai 

5 institution to pay the merchant at least part of the transaction price. 

11. The method of claim 1 , further comprising: 

notifying the customer that the merchant has been paid. 

12. The method of claim 1 , further comprising: 

providing the merchant with a transaction history report including the 
10 payment authentication infomiation. 

1 3. The method of claim 1 , wherein the transaction information includes a 
transaction amount and the method further comprises: 

requesting pre-authorization for the transaction amount from at least 
one financial institution; and 
1 5 transmitting the pre-authorization to the payment component with the 

instructions to pay the merchant on behalf of the customer and the payment 
authentication information. 

14. The method of claim 1 , further comprising: 

authenticating the confidential payment Infomiation as associated with 
20 the customer; and 

storing the confidential payment Information In a database accessible 
to the payment component. 

1 5. The method of claim 14, the method further comprising: 

obtaining the confidential payment Infomiation from the database; and 
25 verifying, by the payment component, the payment authentication 

infomiation and the confidential payment information. 

1 6. The method of claim 1 5, further comprising: 

paying the merchant, if the payment authentication infomiation and the 
confidential payment are verified. 
30 17. A method for securing payment from a customer to a merchant over a 
networi<, peri'onned by a first trusted party component, the method 
comprising: 

receiving a request from the customer to pay the merchant; 
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obtaining confidential payment infomnation associated with the 
customer; 

generating payment authentication information based on the 
confidential payment information; \ 
5 transmitting the payment authentication infonrnation to the merchant; 

receiving from the merchant the payment authentication information 
with a merchant signature; 

verifying the merchant signature and the payment authentication 
information; and 
1 0 paying the merchant on behalf of the customer, 

18. The method of claim 17. wherein the payment authentication 
information is generated based on the confidential payment Information and 
transaction information 

19. The method of claim 17, wherein the payment authentication 
15 information comprises a digital signature of the confidential payment 

information and transaction information. 

20. The method of claim 1 9, wherein the payment authentication 
information with merchant signature is received by a second trusted party 
component and the second trusted party component verifies the merchant 

20 signature and the payment authentication information. 

21 . The method of claim 20, further comprising: 

paying the merchant, by the second trusted party component, on behalf 
of the customer. 

22. The method of claim 20, further comprising: 

25 generating, by the first trusted component, an encryption of the 

confidential payment information and transaction information; 

transmitting the encryption to the second trusted party component, who 
uses the encryption to verify the merchant signature and the payment 
authentication Information. 

30 23, The method of claim 22, wherein transmitting the encryption to the 
second trusted party component Is perfomied by saving the encryption in a 
database accessible to the first trusted party component and the second 
trusted party component 
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24. A method for securing payment from a customer to a merchant over a 
network, performed by a trusted party component, the method comprising: 

receiving an Instruction from the customer to pay the merchant with a 
merchant signature; 
5 obtaining confidential payment information of the customer; 

verifying the merchant signature; and, 

paying the merchant based on the confidential payment infomiation, if 
the merchant signature is verified. , 

25. The method of claim 24, further comprising: 

10 generating payment authentication information based on the 

confidential payment information and transaction information; and 

transmitting the payment authentication infonmation with a third-party 
signature to the merchant. 

26. The method of claim 25, wherein paying the merchant comprises 
15 transferring funds from an account related to the customer to an account 

related to the merchant, 

27. A computer-readable medium containing instructions for causing a 
computer to perfomri a method for securing payment over a network from a 
customer to a merchant, the method comprising; 

20 receiving a request from the customer to pay the merchant, the request 

including a transaction information; 

obtaining confidential payment information of the customer; 
generating payment authentication information based on the 
confidential payment information; and 
25 facilitating payment to the merchant without disclosing the confidential 

payment information of the customer to the merchant by transmitting 
instructions to pay the merchant on behalf of the customer and the payment 
authentication infomiation to a payment component. 

28. The medium of claim 27, wherein the payment authentication 

30 information is generated based on the confidential payment Infomiation and 
the transaction information. 

29. The medium of claim 27, wherein the payment authentication 
Information comprises a digital signature detemnined based on a secret key of 
the customer. 
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30. The medium of claim 27, wherein the trusted party component is a 
computer program signed by a trusted third party, spawned by a first 
computer of the merchant, and executed on a second computer of the 
customer. 

5 31 . The medium of claim 27, wherein the taisted party component is a 
computer program signed by a trusted third party, installed In a first computer 
of the customer, and invol<ed by a second computer of the merchant. 
32. The medium of claim 27, wherein the trusted party component 
executes on a computer of a trusted third party. 
1 0 33. The medium of claim 27, wherein the trusted party component is a 
computer program spawned by or downloaded from a first computer of a 
trusted third party and executed on a second computer of the customer. 

34. The medium of claim 27, further comprising: 

verifying, by the payment component, the payment authentication 
15 information. 

35. The medium of claim 27. further comprising: 

paying the merchant, if the payment authentication information is 
verified. 

36. The medium of claim 27. wherein the transaction information includes a 
20 transaction amount and paying comprises instructing at least one financial 

Institution to pay the merchant at least part of the transaction price. 

37. The medium of claim 27. further comprising: 
notifying the customer that the merchant has been paid. 

38. The medium of claim 27, further comprising: 

25 providing the merchant with a transaction history report including the 

payment authentication information. 

39. The medium of claim 27. wherein the transaction Information Includes a 
transaction amount and the method further comprises: 

requesting pre-authorization for the transaction amount from at least 
30 one financial institution; and 

transmitting the pre-authorization to the payment component with the 
instructions to pay the merchant on behalf of the customer and the payment 
authentication infonnatlon. 

40. The medium of claim 27, further comprising: 
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authenticating the cx^nfidential payment Information as associated with 
the customer; and 

storing the confidential payment information in a database accessible 
to the payment component. 
5 41 . The medium of claim 41 , the method further comprising: 

obtaining the confidential payment infomnation from the database; and 

verifying, by the payment component, the payment authentication 
information and the confidential payment information. 

42. The medium of claim 41 , further comprising: 

10 paying the merchant, if the payment authentication information and the 

confidential payment are verified. 

43. A computer-readable medium containing instructions for causing a 
computer to perform a method for securing payment over a network from a 
customer to a merchant, the method comprising: 

15 receiving a request from the customer to pay the merchant; 

obtaining confidential payment inforrhation associated with the 
customer; 

generating payment authentication infomnation based on the 
confidential payment information; 
20 transmitting the payment authentication information to the merchant; 

receiving from the merchant the payment authentication information 
with a merchant signature; 

verifying the merchant signature and the payment authentication 
information; and 
25 paying the merchant on behalf of the customer. 

44. The medium of claim 43. wherein the payment authentication 
information is generatetl based on the confidential payment infomiation and 
transaction information 

45. The medium of claim 43. wherein the payment authentication 
30 information comprises a digital signature of the confidential payment 

information and transaction information. 

46. The medium of claim 43, wherein the payment authentication 
information with merchant signature is received by a second trusted party 
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component and the second trusted party component verifies the merchant 
signature and the payment authentication information. 

47. The medium of claim 46, further comprising: 

paying the merchant, by the second trusted party component, on behalf 
5 of the customer. 

48. The medium of claim 46, the method further comprising: 
generating, by the first trusted component, an encryption of the 

confidential payment information and transaction information; 

transmitting the encryption to the second trusted party component, who 
1 0 uses the encryption to verify the merchant signature and the payment 
authentication information. 

49. The medium of claim 47, wherein transmitting the encryption to the 
second trusted party component is perfomried by saving the encryption in a 
database accessible to the first trusted party component and the second 

1 5 trusted party component. 

50. A computer-readable medium containing Instructions for causing a 
computer to perform a method for securing payment over a network from a 
customer to a merchant, the method comprising: 

receiving an instruction from the customer to pay the merchant with a 
20 merchant signature; 

obtaining confidential payment Information of the customer; 
verifying the merchant signature; and, 

paying the merchant based on the confidential payment information. If 
the merchant signature is verified. 
25 51 . The medium of claim 50, the method further comprising: 

generating payment authentication information based on the 
confidential payment infomiatlon and transaction information; and 

transmitting the payment authentication information with a third-party 
signature to the merchant. 
30 52 The medium of claim 50, wherein paying the merchant comprises 
transferring funds from an account related to the customer to an account 
related to the merchant, 

53. A apparatus for securing payment over a network from a customer to a 
merchant, the apparatus comprising: 
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a processing unit; 

an input/output device coupled to the processing unit; 

a storage device in communication with the processing unit, the 
storage device Including. 
5 program code for receiving an instruction from the customer to pay the 

merchant, the instruction including confidential payment Information of the 
customer; 

program code for generating payment authentication infonnation based 
on the confidential payment information; and 
1 0 program code for paying the merchant on behalf of the customer 

according to the payment authentication information, wherein the confidential 
payment information of the customer is not disclosed to the merchant, 

54. The apparatus of claim 53, wherein the payment authentication 
information comprises a digital signature determined based on a secret key of 

1 5 the customer. 

55. The apparatus of claim 53, the storage device further comprising: 
stored confidential payment information. 

56. A system comprising: 

a trusted component capable of 
20 receiving an instnjction from a customer to pay a merchant; 

obtaining confidential payment information associated with \he 
customer, 

generating payment authentication infomiation based on the 
confidential payment infomiation, and 
25 transmitting the payment authentication information to a 

payment processor; and 
the payment processor capable of 

verifying the payment authentication information and 
paying tiie merchant on behalf of ihe customer according to the 
30 payment autiientication infomiation. wherein the confidential payment 
information of the customer is not disclosed to tiie merchant 

57. The system of claim 56, wherein the payment autiientication 
infomiation comprises a digital signature determined based on a secret key of 
the customer. 
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58. The system of claim 56, further comprising: 

a shared database operatively connected to the trusted component and 
the payment processor; and wherein the verifying is performed based on a 
secret key of the customer stored in the shared database. 
5 59. The system of claim 56, further comprising: 

a payment component operatively connected to the trusted component 
and capable of preauthorizing the confidential payment infomriation. 

60. The system of claim 59, wherein the trusted component transmits the 
payment authentication information to the payment processor with a 

1 0 preauthorlzation from the payment component. 

61 . The system of claim 60, wherein the payment component is operatively 
connected to the trusted component and the transaction processor and the 
transaction processor is further capable of authorizing payment to the 
merchant based on a preauthorization from the payment component. 

15 



SUBSTITUTE SHEET (RULE 26) 



wo 01/59731 



1/9 



PCT/USOl/04251 




Database 
160 



Trusted Third Party ("TTP") 120 



Fig. 1 



wo 01/59731 



PCT/USOl/04251 



2/9 



No 




205 



Yes 



Extract Encrypted Confidential 
Paynnent Information 



210 



Decrypt Encrypted Confidential 
Payment information 



215 




Verify 



220 



Encrypt Confidential 
Payment Information 
Using TTP's Key and 
User's PIN; and save 



Encrypt PIN For 
Banking Institution 



Encrypt Confidential Payment 
Information and Encrypted PIN 



Save Encrypted Data 
and Order Information 



Compute PAN 



Inform TTP of Encrypted Data 



.240 



245 



250 



260 



270 



c5d 

Fig. 2 



wo 01/59731 



PCTAJSOl/04251 



3/9 




Trusted Third Party ("TTP") 120 



Fig. 3 



wo 01/59731 



4/9 



PCT/USOl/04251 



Start 



Receive Payment Request 
From Merchant 



405 



Signature Not Verified 



Verify Mercliant Signature 



410 



PAN Not Verified 



Obtain and Verify PAN 



415 



Determine Payment 
Tender Types 



420 




425 



Preauthorization? >^''^^ 



Get Payment Information 



440 



Verify Payment 
Information 



445 



^30 



Get Payment 
Information 




435 



Release Funds 



FIG. 4 



wo 01/59731 



PCT/USOl/04251 



5/9 



Customer 
Computer 100 



Merchant 
Server 
110 




..^^^^ 64 

■^^(Optlonal)^ 

63 



Trusted Third Party ("TTP'') 120 



Transaction 
Processor 



Payment 
Transaction 



("PT") Server 



140. 




150. 



Fig. 5 



wo 01/59731 PCT/USOl/04251 

6/9 




Trusted Third Party ("TTP") 120 



Fig. 6 



wo 01/59731 



PCT/USOl/04251 



7/9 



100 



110 



Customer 
Computer 



Merchant 
Server 




Pan Server 



Payment 
Transaction 
Server 



/ 



140 




Transaction 
Processor 



J 50 



Fig. 7 



wo 01/59731 



PCT/USOl/04251 



8/9 



o 
o 



a. 
E 
o 
O 

k. 

£ 

a 
O 




o 


o 




LO 


CO 

\ 


GO 

\ 












O 














Q- 




Q 


O 




"3 






o. 






c 









op 

■■■■ 





wo 01/59731 



PCT/USOl/04251 



9/9 



o 

CO 



c 

CD 

a. 



o 



CM 



1 



1^ 

1 



O 
*> 
(D 

Q 

<D 
Oi 

2 

_g 
55 

TO 
T3 
(= 
O 

o 

(D 
CO 



CO 
CO 

TO 
TO 
Q 



o 

CO 



1 



Q. 
O 



o 

XT 



1 



8 

*> 

Q 

•4— • 

c 













o 






£ 




£ 


<D 


iTtwar 


CO 




oftw 




o 
CO 


CO 










CD 






"to 

5 



o 



7 J 



C35 



O 

o 



o 
cr 



o 

CO 



i3 

CO 

b 
o 

Q> 

> 



o 
m 

C3> 



INTERNATIONAL SEARCH REPORT 



International :atlon No 

PCT/US 01/04251 



A. CLASSIRCATION OF SUBJECT MATTER 

IPC 7 G07F19/00 



According to Imlemallona) Patent Classificallon (IPC) or to both national fdasslflcation and IPC 



B. RELDS SEARCHED 



Minimum documentation searctied (dasstfication system followad fay dasslflcatlon symbols) 

IPC 7 G07F 



Documenlalion searched other than minimum documentation to the extent that such documents are Included in the fields searched 



Electronic data base consulted during the International search (name of data base and, where practical, search terms used) 

EPO-Internal , WPI Data, PAJ 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category • Citation of docunoent, with Indication, where appropriate, of the relevant passages 



Relevant to daim No. 



us 5 883 810 A (ROSEN DANIEL ET AL) 
16 March 1999 (1999-03-16) 



column 


2. 


line 


15 


- line 27 




column 


2. 


line 


47 


- line 55 




column 


4, 


line 


48 


-column 5, 


line 23 


column 


8, 


line 


6 - 


- line 14 




column 


8, 


11 ne 


37 


-column 9, 


line 18 


column 


9. 


line 


63 


-column 10, 


line 5 



1.2.6, 
8-10.13. 
27,28, 
32, 

34-36, 
39-42 



11 



-/— 



m 



Further documents are listed in the continuation of box C. 



Patent family nnembefs are lisled In annex. 



* Spedal categories of died documents 
■A 
'E' 
'V 



docurrtent defining the general state of Ihe art wtilch Is not 
considered to be of particular relevance 

earlier document but published on or after the International 
fHIng date 

document which may throw doubts on priority clalm(8} or 
which is cited lo estabOsh the pubDcation dale of another 
dtallon or other spedal reason (as specified) 
'O" document referring to an oral disclosute, use. exhibition or 
ottier means 

*P* document published prtor to the International filing date but 
later than the prtodty dale dalmed 



'T* later document published after the International filing date 
or priority date and not In conflict wtth the application but 
dted to understand the prindple or theoiy underlying tfte 
Invention 

"X* document 0* particular relevance; the claimed Invention 
cannot be considered novel or cannot be considered to 
Invol/e an Inventive step when the document Is taken alone 

•V document of particular relevance; the claimed Invention 

cannot be considered to Involve an Inventive step when Ihe 
document Is combined wtth one or ittoie other such docu- 
ments, such combination being obvious to a person skilled 
In the art. 

document member of the same patent family 



Date of the actual oompletk>n of the Intemattonal search 

28 June 2001 



Dale of malBng of the International search report 

05/07/2001 



Name and mailing address of the ISA 

European Patent Offk;e. P.a 5616 Patenliaan 2 
NL-2280HVR9swqk 
TeL (+31-70) 340-2040, Tx. 31 651 epo nl. 
Fax: (+31-70) 340-3016 



Authorized officer 



Schofleld, C 



Fonn PCT/1SA/210 (saoond shoet) puV 1002) 



INTERNATIONAL SEARCH REPORT 



C.{Contlnuatlon) DOCUMENTS CONSIDERED TO BE RELEVArTT 



Intematiom 



Icatlon No 



PCT/US 01/04251 



Category * Citation of document, with Indlcation.where appropriate, of the relevant passages 



Relevant to claim No. 



wo 99 07121 A (NETADVANTAGE CORP) 
11 February 1999 (1999-02-11) 



page 6, line 10 - line 21 

page 11, line 8 -page 12, line 6 

WO 95 16971 A (OPEN MARKET INC) 
22 June 1995 (1995-06-22) 



page 6, line 5 - line 16 
page 14, line 6 - line 22 

WO 97 12344 A (DALLAS SEMICONDUCTOR) 

3 April 1997 (1997-04-03) 

page 21, line 23 -page 24, line 25 



GB 2 333 878 A (CITIBANK NA) 
4 August 1999 (1999-08-04) 

page 11, line 14 - line 34 
page 13, line 13 - line 32 
page 14, line 12 - line 31 



I. 2.4,7, 

II, 12, 
27.28, 
30,31, 
37,38,53 



1,3.9, 
27,29. 
34,35, 
53,54, 
56,57 



13,39 
24,50 

17,43 

1,14-17, 
24,27, 
43,50, 
53,56 



Foim PCT/ISA/210 (oontinuadton of second sheat) (Juty 1992} 



INTERNATIONAL SEARCH REPORT 

Information on patent family members 


Internationa tcatlon No 

PCT/US 01/04251 


Patenl document 
cited In search report 


Publication 
date 


Patent family 
nriember(s) 


Publication 
date 



us 5883810 



16-03-1999 



NONE 



WO 9907121 A 



11-02-1999 



AU 
CN 
EP 



8675398 A 
1267380 T 
1004086 A 



22-02-1999 
20-09-2000 
31-05-2000 



WO 9516971 A 22-06-1995 



EP 
JP 
JP 
JP 
OP 
US 
US 
US 
US 
US 



0734556 
11096243 
10312433 
10312434 
9500470 
6205437 B 
6195649 B 
6199051 B 
6049785 A 
5724424 A 



A 
A 
A 
A 
T 



02- 10- 
09-04- 
24-11- 
24-11- 
14-01- 
20-03- 
27-02- 
06-03- 
11-04- 

03- 03- 



1996 
1999 
1998 
1998 
1997 
2001 
2001 
■2001 
2000 
1998 



WO 9712344 A 03-04-1997 



US 
AU 
AU 
CA 
CN 
EP 
EP 
JP 
TR 
US 
US 
US 



5748740 A 
702508 B 
7374596 
2232791 
1198233 
1020821 
0862769 
11513509 
9800565 
6237095 
6105013 
5805702 



05-05- 
25-02- 
17-04- 

03- 04- 

04- 11- 
19-07- 
09-09- 
16-11- 
22-06- 
22-05- 
15-08- 
08-09- 



1998 
1999 
1997 
1997 
1998 
2000 
•1998 
1999 
1998 
2001 
2000 
■1998 



GB 2333878 A 04-08-1999 US 6098053 A 01-08-2000 



Form PCTASA/210 {potanl famOy «nn«x) {July 1992) 



&EST AVAIIABLE COPY 



This Page Blank (uspto) 



